With the advent of the Internet and the World Wide Web (WWW) and the growing popularity of the Internet, the volume of traffic over networks has increased substantially. As a result, the need for high-speed data transmission has increased. Maintaining an efficient flow of information over data communication networks is becoming increasingly important.
Service provider networks generally have any number of subscribers with a wide variety of network utilization requirements. For example, some subscribers may run real-time applications such as video and voice over IP, which involve transmitting and receiving data packets that require a large bandwidth, short latency, small latency jitter, and a reasonably small data loss ratio. On the other hand, other subscribers may only run data processing applications and email, and, generally, transmitting email messages and application data can be done with lower bandwidth, longer latency, and larger latency jitter. It is not usually critical that email be delivered instantly since email services can usually tolerate longer latencies and lower bandwidth utilization than other services. As a result, different subscribers have different needs based on any number of factors including the type of applications a subscriber may be using.
Since service providers charge a fee for bandwidth utilization, customers often pay different amounts for different levels of service. However, providing different levels of service to different subscribers can often be a challenge. One problem is managing bandwidth utilization among several subscribers each with different level of service agreements. To do so, service providers often place a volume limit on the amount of network traffic that can be sent and/or received to/from each subscriber based on each subscriber's level of service. This is known as a network traffic volume limit. Whenever a user exceeds his or her allocated network traffic volume limit, a decision is made to take action based on a predetermined policy. Usually this decision is implemented in an Authentication, Authorization, and Accounting (AAA) module or process.
An AAA process provides three important functions in networks. Essentially, an AAA process is a program that handles user requests for access to network resources and provides authentication, authorization and accounting services. The AAA process typically interacts with network access and gateway servers and with databases and directories containing user information. The user information may include a particular subscriber's bandwidth utilization network traffic volume limits, and other user-specific information. Authentication, authorization, and accounting (AAA) is a term for a framework for intelligently controlling access to network resources, enforcing policies, auditing usage, and providing information necessary to bill for services. These combined processes are considered information for effective network management and security. As the first process, authentication is essentially proving who you are. That is, authentication provides a way of identifying a user, typically by having the user enter a valid username and password before access is granted. The process of authentication is based on each user having a unique set of criteria for gaining access. The AAA process compares a user's authentication credentials with other user credentials stored in a database. If the credentials match, the user is granted access to the network. If the credentials don't match, authentication fails and network access is denied. Following authentication, a user must gain authorization for doing certain tasks. Authorization is defining what a subscriber is and is not allowed to do. After logging into a system, for example, the user may try to issue commands. The authorization process determines whether the user has the authority to issue such commands. In this way, authorization is the process of enforcing policies and determining what types or qualities of activities, resources, or services a user is permitted. Usually, authorization occurs within the context of authentication. Once you have authenticated a user, they may be authorized for different types of access or activity. Finally, accounting measures the resources a user consumes during the access. This can include the amount of system time or the amount of data a user has sent and/or received during a session. Accounting is carried out by logging session statistics and usage information and is used for authorization control, billing, trend analysis, resource utilization, and capacity planning activities.
The current standard by which devices or applications communicate with an AAA process is the remote authentication dial-in user service (RADIUS). Thus, a server that communicates with an AAA process (client) is often called a RADIUS server.
An AAA process is used to implement network policies such as network volume limits. Referring to FIG. 1, which illustrates an exemplary network element according to the prior art. Exemplary system 100 illustrates a prior art system for connecting Subscribers 135 with Internet and/or Services Providers 133. For the purposes of this application, service providers may be any the following: a company which provides subscribers with an Internet gateway and/or Internet content; a telecommunications company which provides network infrastructure; a company or firm which provides a Virtual Private Network (VPN) connection to its employees; or any network-addressable entity that accepts and executes requests from consumers. It can be a mainframe system, a component, or some other type of software or hardware system that executes service requests.
In FIG. 1, Network Element 101 communicates with RADIUS Server 125 across a Communication Link. Various information such as network traffic volume limits and policies is communicated. Network element 101 also includes a number of packet processors including Ingress Packet Processors 111 and 112, and Egress Packet Processors 117 and 118 for receiving and forwarding data packets across the network. That is, Network Element 101 provides a channel of communication between Subscribers 135 and Internet and/or Service Providers 133 via the various Ingress Packet Processors 111 and 112, and Egress Packet Processors 117 and 118 across a network mesh such as Network Mesh 309, which may be any network mesh known in the art. For example, Network Mesh 309 may be a switch fabric, which includes a full mesh such that each of Ingress Processors 111, 112, and Egress Processors 117 and 118 are coupled to one another. Further, Network Element 101 includes Control Card 123 which includes AAA Process 122. AAA process 122, in one embodiment, is a BSD process. BSD processes refer to any software process known in the art as Berkeley Software Distribution process of a UNIX operating system (OS), also referred to as BSD UNIX. Control card 123 is also coupled to each of the Ingress and Egress Packet Processors 111, 112, 117 and 118 through Network Mesh 309.
As discussed above, AAA Process 122 of Control Card 123 performs the three primary services required by a RADIUS server such as RADIUS Server 125. All authentication, authorization, and accounting are performed on Control Card 123 as it monitors the network traffic from Subscribers 135 to Internet and/or Service Providers 133 and vice versa.
Referring to FIG. 2, which illustrates network traffic volume limit reporting in an exemplary network element according to the prior art. Exemplary prior art system 200 includes Network Element 201 and RADIUS Server 221. Network Element 201 includes Control Card 203 which includes AAA Process 217. Network Element 201 also includes Ingress and Egress Packet Processors 207 and 208 respectively. Data sent across a network from subscribers (not shown) to service providers (not shown), and vice versa, traverses through Ingress and Egress Packet Processors 207 and 208 respectively. RADIUS Server 221 sends a network traffic volume limit value configured for each subscriber on the network to Network Element 201 where it is stored in AAA Process 217 on Control Card 203.
During operation, Ingress Packet Processor 207 and Egress Packet Processor 208 both report network traffic volume exceeded events directly to AAA Process 217 through Ingress Traffic Volume Exceeded message 211 and Egress Traffic Volume Exceeded message 213 respectively. To do this, Ingress Process 207 and Egress Processor 208 maintain a set of counters (not shown) which determine the network traffic volume through each of the respective packet processors. Each of the packet processors reports the traffic volume to AAA Process 217 of Control Card 203.
Whenever the network traffic volume limit is exceeded in either the Ingress or Egress directions, AAA Process 217 notifies RADIUS Server 221. Specifically, whenever the network traffic volume limit is exceeded in the Ingress direction through Ingress Packet Processor 207, AAA Process 217 sends Accounting-Interim-Update (Reason: Ingress Volume Limit Exceeded) message 227 to RADIUS Server 221, and whenever the network traffic volume limit is exceeded in the Egress direction through Egress Packet Processor 208, AAA Process 217 passes Accounting-Interim-Update (Reason: Egress Volume Limit Exceeded) message 228 to Server 221. AAA Process 217, then, implements a predetermined policy received from Server 221 via Network Policy Message 239. Network Policy Message 239 indicates what action is to be taken. For example, RADIUS Server 221 may have in place a policy to disconnect a subscriber (drop packet forwarding for the subscriber) whenever his or her volume limit is reached. Alternatively, the policy may be to re-direct a subscriber to a website where the subscriber may purchase more bandwidth.
In prior art System 200; however, there is always a delay between the moment a subscriber exceeds the volume limit and the time it takes for the packet processors to report their respective traffic volume to the AAA process to implement the network policy. This is because current systems, like prior art system 200, receive network traffic volume limit reporting at periodic intervals. The periodic interval is generally global across all subscribers and is determined by the number of subscribers who are loading the system at any particular point. As the subscriber loading increases, it becomes prohibitive to report traffic volume at frequent intervals. This is because the number of messages passed back and forth between the various network elements becomes increasingly large as subscriber loading increases leading to longer periods between reporting.
Additionally, in prior art systems such as those depicted in FIGS. 1 and 2, the volume limits could not be aggregated when they were reported by Ingress Processor 207 and Egress Processor 208. This is because Ingress Processor 207 and Egress Processor 208 are two different entities that have different processors, memories, addressing schemes, and etc.